Version control system for data

Logs commits of file changes retrievable at any time

Version control

Collaborate

Storage for every possible file type, e.g. Supp Material

Dynamic loading of stored links and programs

require(RCurl)
script <- getURL("https://raw.githubusercontent.com/darwinanddavis")
eval(parse(text = script))

Fork and clone a plethora of public data, code, material

Reproducible

Unlimited

Transparent

Shareable

Annotation

N <- 20 # set rep number  
p <- rep(rnorm(100),N) # repeat a random normal dist of 100 integers N times  

This is a git GUI tutorial and not the best way to use git.

I'd rather you move towards open-access and reproducible research than be deterred by the git user experience.

See Part II

1. Create a local repo

2. Add your files

3. Upload changes to a remote Github repo

Now we push the changes we made from our local repo to our Github cloud.

1. Create a new Github repo. Name is using best practice, e.g. no spaces
   
2. Don't create a README

• Uncheck the box 'Initialise this Github with a README'

1. Go to the repo loading page on your Github

2. Drag and drop the file/s onto the screen

3. Add a commit message, e.g. 'init' 'updated table2', etc

This creates a git repository on your local machine complete with version control.

Why clone?

You can dump the contents of any public repo, including its complete version history, onto your own computer, then upload it onto the cloud.

- Complete control and ease of workflow

- Automate your commands, e.g. schedule an automatic daily backup

- Transparent history

- A steeper learning curve, but worth the investment